The Xconq world/area is a two-dimensional grid of fixed shape and size. You can treat it as representing part of a planet in space, and set up parameters simulating that, or just make it be itself and not address the question of the surrounding context. The appropriate choice depends on how much realism and complexity you need. Most computer games don't bother with this detail; for instance, a game set in an underground dungeon doesn't usually need to compute daylight, weather, or seasons. However, these same details may be very useful for games set outdoors.
Once you've decided whether the area is to be part of a planet or not, you can address the question of size and shape. You have two choices for shape: hexagon and cylinder. (See the players chapter for pictures of these.) The important thing for you as a designer is that the cylinder wraps around, while the hexagon is bounded on all sides. One consequence is that games involving pursuit will be quite different; on a cylinder, the chase can go 'round and 'round forever, while on a hexagon, a fleeing unit could be cornered. Cylinders have a disadvantage in that there is no obvious "starting place" for coordinates, scrolling, etc, so there is a navigation and orientation problem for players, especially if the world is randomly generated and not the familiar continents of the Earth. In fact, players will often not even realize that a world is a cylinder and will assume that the edge of the display is the edge of the world! To make a cylindrical area, set the circumference of the world equal to the width of the area. Otherwise, the area will be handled as a hexagon.
You can choose either to set a fixed size using the area form,
or allow players to set the actual size via the world-size variant,
in which case you can define the allowable range of sizes.
Worlds need not be really large. Larger worlds are harder for players to manage, they take longer to display, and can consume prodigious amounts of memory (since they are represented as arrays internally, for speed). The ideal range of sizes depends primarily on the size and speed of units. A 60x60 area in a game with units whose speed is 1 means that they will take 60 turns to cross, while units with a speed of 20 take only 3 turns, so they make the world "feel smaller". As another example, in the standard game, a 20x20 area allows player to come to grips quickly, but it also means that each player's units might be within attack range right from the outset, which has a drastic effect on strategy. For exploration-oriented games, larger worlds are more interesting.
The best technique for designing the terrain of a world is to use the designer tools provided with Xconq. The details of how these tools work depends on the interface, but in general they resemble the tools found in paint programs. Some interfaces also give you the option of rescaling the map, so that you can fine-tune the size and positioning of the terrain.
Another technique is to write a program that translates data from another
source (such as NASA satellite data) into Xconq format.
However, if you take a rectangular array of data and just wrap an
area (terrain ...)) form around it,
then everything will appear to be tilting to the left.
To fix this, have your program map the cell at x, y
in the rectangular array to x - y / 2, y before writing.
You must discard values whose new x coordinate is negative,
or else wrap them around to the right side of the area, although
that is usually only reasonable for cylindrical areas.
The crudest technique is to try to build terrain by using a text editor. The coordinate system is Cartesian oblique, with the y axis tilted to form a 60-degree angle with the x axis, so it can be difficult to relate typed-in characters to the final appearance. Landforms in the file should appear to be leaning to the left, if they are to appear upright during play. However, sometimes text editing is necessary, for instance when you need to change every instance of a terrain type to something else. (Incidentally, some of the large real-world maps in the library were produced by coding all the terrain types from an atlas onto graph paper, typing them in, then fixing the tilt as described above.)
Incidentally, areas should have some distinguishing terrain
around the edges; this prevents player confusion that sometimes
happens when there is no other clue as to where the edge might be.
However, this is not enforced by Xconq, and you can put
whatever you like along the edges.
Randomly generated worlds normally use the value of
the global variable edge-terrain.
The random way to get terrain for a world is to use one of several synthesis methods built into Xconq.
Totally random terrain is available via the synthesis method
make-random-terrain. This just randomly chooses a terrain
type for each cell, using the weights in the occurrence
property of each type. An occurrence of 0 means that the
type will never be placed anywhere.
This method produces a sort of speckly-looking world,
and is better for testing than for actual play. Still, if you have
two types vacuum and solar-system, then a form like
(add (vacuum solar-system) occurrence (20 1))
will give you a nice starfield for a space game.
The fractal world method make-fractal-percentile-terrain
descends from the most venerable part of Xconq
(it was once a piece of Atari Basic code). It uses a fractal algorithm
along with percentile-based terrain classification to make realistic-looking
worlds with terrain and elevations.
To use this method, you first specify how many, what size, and what height
of blobs to splash onto the world,
and how many times to average cells with their
neighbors. Then you specify the subdivision of all the possible altitudes
and moisture levels into different kinds of terrain.
For instance, desert in the standard terrain ranges from
sea level (alt-percentile-min = 70%)
to high elevations (alt-percentile-max = 93%) but only
in the lowest percentiles of moisture (wet-percentile-min = 0%,
wet-percentile-max = 20%).
It is important that all percentiles be assigned
to some terrain type, or the map generator will complain and subsitute
terrain type 0 (the first-defined type); when designing
terrain percentiles, it is helpful to make a chart with altitude percentiles
0-100 on one axis and moisture percentiles on the other.
Note that overlapping on this chart is OK, and the terrain generator
will pick the lowest-numbered terrain.
Also note that you don't have to include every terrain type.
The alt numbers are also used to compute elevations
for games that need them, but the wet numbers need
not have anything to do
with water at all; they could just as easily represent smog levels or
vegetation densities.
If you only want to use one of the two layers, just set the percentiles
for the other to be 0 - 100 for all terrain types.
[should have an example]
The method make-maze-terrain produces a maze consisting
of a mix of "solid", "passageway", and "room" terrain.
It uses the maze-room-density and maze-passage-density
properties of each terrain type to decide
how much of each to use for rooms and passages.
The method first does random terrain generation, using the
occurrence property to decide how much of each terrain
to put down (remember that occurrence defaults to 1 for
all terrain types).
Then it carves out rooms, and passageways between them.
The passages and rooms are guaranteed to be completely connected.
The method make-earth-like-terrain attempts
to model the natural processes and generate terrain as similar as possible
to what is observed on Earth today.
You should note that at least one method for synthesizing terrain must be available, unless you can guarantee that terrain will be loaded from a file. The following subsections describe optional additional synthesis methods that you can include.
You can use the make-rivers method to add rivers to the world.
Rivers are basically water features that depend on terrain elevations,
so they won't be generated unless both a river terrain type (either
border or connection) and elevation data is available.
You get them by specifying a nonzero chance for some type of
terrain to be the location of a headwater (river-chance).
Xconq doesn't have any intuition about the behavior of water;
it will happily trace rivers all the the way down to the bottom of the sea.
Use the liquid property to tell make-rivers
what types that rivers cannot touch.
The method still traces the river's course, and resumes modifying
terrain when possible, which means that the river can appear
as both the inlet and outlet from a lake.
The make-roads method is a fairly generic method.
It just picks pairs of units randomly and runs a road between them,
attempting to share road segments and route through favorable terrain.
Although simplistic, the results look pretty good.
You can make short bridges by tweaking the road density appropriately. Just allow roads from land to water, and water to land, but not from water to water.
Note that this method is only useful if there are actually units for the roads to connect.
For many games, it is useful to have independent units scattered randomly
across the world. For instance, gold mines and treasure hoards would be
good for an exploration game, and independent castles for a medieval game.
You can set this up with the make-independent-units method.
Xconq is basically a 2-dimensional game, but you can emulate a third dimension by defining elevations for terrain and altitudes for units above and below the terrain.
The main use of altitudes is to control interactions between certain kinds of units, particularly aircraft. For instance, a high-altitude bomber should be able to pass over a ship and under a satellite with impunity. In general, you define the "operating altitudes" of a unit, so in the example above, you could say that a ship is always at the surface, bombers operate at 1-10 km, and satellites at 100-10,000 km. If a unit has more than one operating level, then it can move up and down by normal movement actions.
Also, most details such as speed and material consumption are the same for a unit at any altitude. (Yes, such things vary in real life, but the effects are usually minor within the unit's normal operating range.) Altitudes have a significant effect on combat. A unit at some altitude can only attack units at a specific range of altitudes up and down. Using the example again, you could define fighter aircraft to operate at 0-20km and be able to attack up and down 5km, while bombers can attack up to 10km down (i.e. down to the ground), but not up. Satellites remain invulnerable.
All this applies equally to units underground and undersea.
[need info about setting up other layers]